v26.45.0 release notes - #39477

The v26.45.0 release-note train, one commit per snapshot. Dates in RC snapshots are provisional until the release ships; the final snapshot sets the real dates.

rc.1 adds the ## v26.45.0 section — 7 Improvements, 1 Agent Skills entry, 7 Bug Fixes (15 published entries from 16 PRs) — and the v26.45 row in the self-managed operator compatibility table. No Features section: nothing in this snapshot's 229 in-scope PRs rises to one. The closest candidate is sum/avg over interval, which fills the last gap in the aggregate surface for a core type rather than adding a capability worth its own heading.

rc.2 adds 1 Bug Fix from 1 PR in scope — zero-downtime cut-overs stalling for hours when the incoming environmentd re-consolidated its whole catalog snapshot before every fence attempt and so lost the race against the serving instance's advancing frontier (#39482). Nothing omitted, nothing Borderline.

rc.3 adds 1 Improvement and amends another, from 2 PRs in scope. New: quieter logins with identity-provider group sync (#39434). Amended in place: rc.1's subject-alternative-name bullet now carries the exact-match pinned-CA carve-out (#39459) and cites both PRs — see the reviewer check below for why that is a replacement rather than a second bullet. Nothing omitted, nothing Borderline.

rc.4 adds nothing, and its commit is intentionally empty. The increment is two items — #39549 (borderline, omitted; see the reviewer check below) and the materialize-bot version-bump commit ba9b30921 — and the provisional dates are unchanged, so there is no edit to make to either file. An RC whose whole increment is a within-train repair is a legitimate outcome rather than a gap; v26.39.0 rc.3 is the precedent for a zero-entry snapshot on this layout, landed the same way. The empty commit is what records rc.4 as applied, so please keep it on any rebase — the commit subject is the ledger that stops a later run re-applying the snapshot.

Provisional dates: Cloud 2026-10-08, Self-Managed 2026-10-09 — the first Thursday strictly after the v26.45.0-rc.1 tag's commit date (2026-10-02T02:23:01Z, a Friday), plus one day. Anchored on rc.1, so rc.2, rc.3 and rc.4 introduce no drift and none of them touches the compatibility YAML. Expect the final snapshot to move these one day earlier: both of the last two trains shipped on the Wednesday before the estimate (v26.43.0 on 2026-09-23 against 2026-09-24; v26.44.0 on 2026-09-30 against 2026-10-01). The estimate is kept as the rule specifies rather than pre-corrected. Note that the train has now run four candidates across a weekend — rc.4 was cut Monday 2026-10-05 at 14:28:59Z, 2 d 15 h after rc.3 and by far the widest gap of this train — so the Thursday target is tighter than it was at rc.1.

⚠️ Reviewer checks

• rc.4's one PR, #39549, is omitted as borderline, and there is no entry to move if you disagree. It pins jemalloc's allocator page back to 4 KiB on aarch64-unknown-linux-gnu (one line in .cargo/config.toml), repairing a regression #39339 introduced inside this same unreleased train when it bumped jemalloc 5.3.0 → 5.3.1 and silently took the default aarch64 Linux allocator page to 64 KiB. The measured effect is large — at equal post-restart age against v26.44.0, environmentd active-minus-allocated 55 MB → 490 MB and 84 MB → 558 MB on two us-east-1 canaries, the largest canary clusterd pods 0.19 GB → 1.70 GB, local VmRSS 32% higher on environmentd — which is why this is filed Borderline rather than as a plain build omit. It is nonetheless omitted because no released version ever ran the 64 KiB page: build(deps): bump the jemalloc crates #39339 was itself omitted at rc.1 as a dependency bump, so nothing published describes the behaviour, and a user upgrading from v26.44.0 sees the same allocator page before and after. Publishing it would mean writing a bullet asserting that memory use is unchanged from v26.44.0 — a non-statement. If the release owner wants the work visible, an internal sign-off note is the right vehicle, not a release note. Separately worth an eye: this was caught by a release sign-off sweep rather than by CI, and @antiguru confirmed on the PR that "moving to 64kb page size was not a deliberate choice" — a dependency bump that silently changes allocator behaviour may deserve a follow-up guard.
• rc.3 rewrites an rc.1 bullet rather than adding one, and that is deliberate. #39459 repairs a regression #39415 introduced earlier in this same unreleased train, so no released version ever showed the failure and a standalone "fixed" bullet would be false for every reader upgrading from v26.44.0. What it changes for that reader is the scope of rc.1's caveat: a schema registry server certificate byte-for-byte identical to its configured SSL CERTIFICATE AUTHORITY needs no reissue. The narrower alternative, if a reviewer prefers one bullet per snapshot: revert to rc.1's wording and accept a published caveat broader than the shipped behaviour — the safe-direction error, but still wrong. build: pin jemalloc's page size to 4 KiB on aarch64 Linux #39549 above is the same family with a cleaner resolution: there the causing PR was never published, so there was no bullet to amend.
• rc.3's group-sync entry is published over the rollout-lever default rule, and the LaunchDarkly evidence is weaker than the precedent it leans on. oidc_group_role_sync_enabled reads false at the tag (src/adapter-types/src/dyncfgs.rs:203-208) and is in KNOWN_CROSS_ENV_DIVERGENCES, not KNOWN_MISSING_FROM_LD — so an LD flag exists and its served value knowingly differs by environment, which is consistent with a per-customer opt-in but is not proof the feature is on. It is published on four grounds: the flag is environment-scoped, v26.40.0 rc.1 already published a fix on this same gated path (#38410), the capability was announced GA one release earlier, and the PR ships the new behaviour in the published sync-idp-groups.md docs page in the same diff. This confirmation is still owed by the release owner as of rc.4; if it comes back negative, that is the entry to cut — the certificate entry is unaffected.
• Two entries are breaking-ish and need an upgrade-time action, and the notes schema has no "Breaking changes" heading. The stricter Kubernetes API server certificate verification (#39316) and the schema registry / COPY FROM subject-alternative-name requirement (#39415 + #39459) both sit in Improvements, phrased around the action a user must take. A reviewer may want them moved or called out more loudly. Related and omitted: #39351 moves all S3/AWS traffic onto rustls and webpki — if the same SAN strictness applies to a custom S3 endpoint in a Self-Managed deployment, it belongs in the same note; the PR does not say either way.
• Two zero-downtime cut-over fixes are published separately, by design. rc.1's #39151 (previous-generation replicas left running) and rc.2's #39482 (lost fence race against a large catalog audit log) are distinct failures with distinct mechanisms, so they are not merged. If a reviewer prefers one combined "zero-downtime cut-over reliability" bullet, that is an editorial call to make at final. Also deliberately unpublished on catalog: skip consolidation on syncs that apply no updates #39482: it is a regression since v26.22.0 by the author's own statement, and the fix does not cover syncs that do apply updates (DDL issued during takeover still consolidates the full snapshot) — the PR gives no measurement of that residual, so it is not claimed.
• Curated metric sinks are withheld for the fourth consecutive train (v26.39.0, v26.40.0, v26.42.0, v26.43.0). Three real fixes are Borderline behind enable_metric_sink, which reads false at this tag. Confirm with the release owner: if the flag is on in v26.45.0, publish #39332 (clearest candidate — it also removes the unattributable series from the metric's label set), #38910, and #39337. #39337 deserves a second look even if metric sinks stay off — the coordinator panic it fixes is reachable by any superuser via ALTER SYSTEM SET disabled_metric_sinks = '', a plain system variable with no feature-flag check.
• The schema-registry TLS fix is rc.1's closest call on the include side. #39362's only observed failures are in CI (test/kafka-auth, SS-115) — no customer report, no database-issues reference. It is published because the defect is in shipped code on a shipped path (librdkafka leaves a stale OpenSSL error on the tokio worker's error queue). If a reviewer wants only customer-observed fixes published, this is the entry to cut.
• The introspection-logging latency numbers were measured on one noisy shared machine. #39179's own caveat is not in the published entry, and #39178 adds metrics to confirm the effect elsewhere. A reviewer who wants the figures hedged should say "about 9–14 ms" or cut the halved-SELECT clause, which is the softer of the two claims.
• The materialized-view correction-buffer stack is omitted for want of an end-to-end number. #38894 / #38895 / #38896 are on the default-on path (enable_compute_correction_v2 is true) with real figures — 3503 ms → 1897 ms, 1.6x–2.0x — but every one is a bench of the buffer's own insert path, not of materialized-view ingest. If the compute team can supply a hydration or lag number, publish these as one Improvement; the per-clause provenance is already drafted in the review notes.
• The documented local kind install fails today, and the fix is a docs change. #39149 is omitted as documentation (the rubric excludes the class), but following the guide on v26.42.0 crash-loops environmentd with the exact Invalid Parquet file. Corrupt footer defect that #39115 fixes and this release publishes. Same call as #39125 in v26.44.0 rc.1. If a reviewer restores it, it is a Bug Fix.
• This branch will need a rebase if the v26.44.0 or v26.43.0 docs PRs merge first. _index.md here jumps from ## v26.45.0 straight to ## v26.43.0 — the v26.44.0 section is absent because that train's PR (#39138) has not merged, and the same holds for the v26.44 row in the operator-compatibility YAML. Whichever PR merges second needs the rebase to get the sections and rows into version order.
• Two PRs are excluded as already published by an earlier train — #39300 (published in v26.44.1 as "Lower balancerd memory use per connection") and #39130 (the materialize half of the materialize-docs → mz-docs rename, whose user-visible half shipped in v26.44.0). Accounted for in omitted.md under "Already published in an earlier release".

Inclusion rate: rc.1 is 7.0% (16/229), inside the usual 5–15% band; rc.2 is 1/1, rc.3 is 2/2 and rc.4 is 0/2, which is the expected shape for a late RC — the set is cherry-picks a release manager has already filtered down, and at a denominator of one or two the percentage carries no signal. rc.1's denominator is dominated by automation: 125 of the 225 materialize PRs are dependency bumps, 65 of them a single Dependabot fan-out of the materialize-terraform-self-managed modules from 13.10.0 to 13.12.1 across five test/terraform directories — #39282 groups future Terraform releases into one PR so it does not recur. Strip the dependency bumps and rc.1's materialize side is 15 included out of 100 (15%). A further 22 PRs are CI/test-harness repair and 14 are documentation.

The agent-skills windows for rc.2 (2026-10-02T02:23:01Z, 2026-10-02T22:33:36Z] and rc.3 (2026-10-02T22:33:36Z, 2026-10-02T23:08:27Z] are both empty, re-checked against a widened query. MaterializeInc/agent-skills#88 (an automated mz-docs regeneration, omitted as every prior run of that workflow was) lands in rc.4's window (2026-10-02T23:08:27Z, 2026-10-05T14:28:59Z], not final's — rc.2 and rc.3 both predicted final on the assumption that rc.3 was the last candidate, and rc.4 being cut opened a window first. The windows still abut exactly and nothing is double-counted. MaterializeInc/agent-skills#79 merged 15 min 26 s after rc.4's upper bound and falls to final; the margin is small enough that a date-only window would have wrongly pulled it in, so full ISO timestamps were used.

Snapshot drafts (with PR links) in mz-skills:

• rc.1: release_notes.md / omitted.md
• rc.2: release_notes.md / omitted.md
• rc.3: release_notes.md / omitted.md
• rc.4: release_notes.md / omitted.md

Borderline PRs omitted: rc.1: 12 — review borderline calls, rc.2: 0 — none, rc.3: 0 — none, rc.4: 1 — review borderline call